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1. Introduction 

Sharing QCD configurations world-wide via the ILDG [jl|, ^ ^ requires standards of nota- 
tion and terminology for metadata of configurations such as lattice actions and sizes used in simu- 
lations. For this purpose, the Metadata Working Group (MDWG) ^ has been working [Q, on 
designing an XML-based markup language QCDml [^], a set of rules for XML instance documents 
(IDs). IDs are stored in regional grid databases which are aggregated together to form the ILDG 
Metadata Catalogue (MDC). Because this service is queried by users, contributors (and hopefully 
users) are advised to understand QCDml. 

After the first working version [Q] was released in 2004, the MDWG has revised the QCDml 
schema several times [0]. Although our design strategy and the global structure of QCDml re- 
main unchanged, many improvements have been made to meet community requirements, some of 
them being incompatible with previous versions. In this article, we present key ingredients of the 
QCDml, based on the latest release. 

2. QCDml Structure 

QCDml defines the ensemble XML and the configuration XML whose structure is shown below. 
The former describes metadata common across an ensemble such as <physics> information, while 
the latter contains configuration specific information such as a trajectory number <update>, a tag 
<series> which distinguishes different runs in one ensemble, <precision> of the configuration, 
and an <avePlaquette> value. The <algorithm> parameters can be stored in either of the XML 
documents. The <management> part includes information of who and when data and metadata are 
submitted or modified. The <implementation> part contains information of machine and code used 
in simulations. 

The two XML IDs and the configuration itself are linked together in the following way. The 
Markov Chain URI (MCU) in <markovChainURI> is an unique ensemble name and appears in 
both XML documents. The Logical File Name (LFN) in <dataLFN> of the configuration XML 
is an unique configuration name and is embedded in the configuration file [^]. The format of the 
MCU (LFN) is "mc:(lfn:)//(Name of Regional Grid)/(Regional Grid Dependent String)". 

Root elements, <markovChain> for the ensemble XML and <gaugeConfiguration> for the 
configuration XML, contain names of namespaces (xmlns=) and URL's of schema (schemaLoca- 
tion). A two digit version number of the QCDml (currently 1.4 for ensemble and 1.3 for configu- 
ration) is appended at the end of the namespace, and more one digit release number is added to the 
schemata file to identify backward compatible updates. 

ensemble XML 

<markovChain xmlns :xsi="http: / / www .w3. org/200 1 /XMLS chema- in stance" 
xsi : schemaLocat ion="http : / /www . Iqcd . org/ ildg/ QCDml/ ensemble 1 . 4 

http : //www. Iqcd. org/ ildg/QCDml /ensemble 1 . 4 /QCDmlEnsemblel . 4 . 1 . xsd" 
xmlns="http : / / www . Iqcd . org/ ildg/QCDml/ ensemblel . 4 "> 
<markovChainURI> 

mc: //JLDG/CP-PACS+JLQCD/RCNF2+l/RC2 8x5 6_B2 050Kud0135 60 
</markovChainURI> 
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<management / > 
<physics/> 
<algorithm/ > 
</mark;ovChain> 

configuration XML 

<gaugeConf igurat ion xmlns : xsi="http : / / www .w3 .org/200 1 /XML Schema- in stance " 
xsi : schemaLocat ion="http : / /www . Iqcd . org/ildg/ QCDml/ configl . 3 

http : //www. Iqcd. org/ ildg/QCDml/ configl . 3/QCDmlConf igl . 3 . . xsd" 
xmlns="http : / / www . Iqcd .org/ildg/ QCDml/ configl . 3"> 
<management /> 
<implementat ion/> 
<algorithm/> 

<precision>double</precision> 
<markovStep> 

<markovChainURI> 

mc: //JLDG/CP-PACS+JLQCD/RCNF2+l/RC2 8x5 6_B2 050Kud0135 60 

</markovChainURI> 

<series>2</series> <update>0022 00</update> 
<avePlaquette>6 . 04 32 65 96981212e-01</avePlaquette> 
<dataLFN> 

Ifn: //JLDG/CP-PACS+JLQCD/RCNF2+1/RC2 8x5 6_B2050KudO 13560-2-0022 
</dataLFN> 
</markovStep> 
</ gaugeConf igurat ion> 

3. Physics Part 
3.1 Structure 

The <physics> part of the ensemble XML consists of <size>, <action> and optional <ob- 
servables>. The <size> section looks like <size> <elem> <name>X</name> <length>16</length> 
</elem> (lengths in Y,Z,T directions) </size>. 

The <action> section is a central part of the ensemble XML. The example below illustrates the 
structure: 

<action> 

<gluon> <iwasakiRGGluonAction/> </gluon> 

<quark> <npCloverQuarkAction/> <npCloverQuarkAction/> </quark> 
</action> 

Each lattice action is described in an element block (e.g. <iwasakiRGGluonAction/>) whose name 
is easily understood. This strategy is taken, firstly to assign an unique name to each action, and 
secondly to realize a hierarchal structure of action trees in the schemata. Note that we repeat quark 
action blocks if coupling parameters ai^e different, e.g. for the Nj = 2 + \ case. Fig. |T] shows a 
typical quark action. An action block consists of 

• <glossary>, the URL of a document prepared by contributors using either text, pdf, ps, tex, 
or xml formats. The document describes full details of the action. 
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Figure 1: A graphical representation of the XML schemata for the clover quark action. 



• gluon/quark field information, <gaugeField> or <quarkField>, which includes <boundaryCon- 
dition> and supplemental information such as <representation> and <normalisation>. 

• <numberOfFlavours> for quark actions. 

• optional <linkSmearing> block which is explained below. 

• list of coupling parameters together with tadpole factors for tadpole improved actions. 

The last optional block <observables> of the <physics> part displays values of measured phys- 
ical quantities. Each element of the list has the following structure: <elem> <name/> <value/> 
<err/> <glossary/> </elem>. Currently, <name> of <observables> is one of ampi {aniji), amrho 
(amp), mpi_mrho {nij^/mp), arO (aro) and arl {ar\). QCDml supports only dimensionless quanti- 
ties, because dimensional quantities (e.g. lattice spacing) cannot be regarded as properties of an 
ensemble. 

3.2 Details of actions 

The current version of QCDml supports the following lattice actions (lower camel case con- 
vention). 

• gluon actions: plaquetteGuonAction, iwasakiRGGluonAction, DBW2GluonAction, Luscher- 
WeiszGluonAction, treeLevelSymanzikGluonAction, tpLuscherWeiszGluonAction, anisotropic- 
WilsonGluonAction, anisotropicTpWilsonGluonAction 

• quark actions: KSquarkAction, asqTadQuarkAction, wilsonQuarkAction, cloverQuarkAc- 
tion, tpCloverQuarkAction, npCloverQuarkAction, wilsonTMQuarkAction, domainWallQuark- 
Action, fatLinklrrelevantCloverQuarkAction, anisotropicWilsonQuarkAction, anisotropic- 
CloverQuarkAction 
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Figure 2: Coupling parameters of the anisotropic 
tadpole improved Wilson gluon action. <xiO> is the 
bare gauge anisotropy and <anisoDirection> is the 
direction of anisotropy. 




cSWTemporal 



Figure 3: Coupling parameters of the anisotropic 
clover quark action. Wilson parameters are op- 
tional. 



A list of coupling names for each action can be found in Ref. [10]. 

There are currently two examples of non-unique notation in QCDml. 

• Gluon actions with plaquette and six-link loops (sixLinkGluonAction), such as 
<DBW2GluonAction>, are mathematically written as 

S = [5 X (co ^ plaq. + ci ^ rect. + C2 ^ parallelogram + C3 ^ char) . 

The QCDml supports two standard normalisation of couplings; 

Co = 1 , Co + 8ci + 8c2 + I6C3 = 1 . 

The normalisation is marked up as a value of the <normalisation> element, cO_is_one for 
the former (recommended for tadpole improved actions) and cs_sum_to_one for the latter 
(recommended for others). 

• The current version of QCDml supports some anisotropic actions. See figs. |2| and ^ for exam- 
ples. Note that one can choose either (JCspatiah ^Temporal) or (/x,mass) notations for anisotropic 
wilson/clover quark actions. 



3.3 Link smearing 

Smearing link variables is becoming one of the standard technologies for improvement. QCDml 
supports marking up smearing as an optional <linkSmearing> block in all quark actions. Link 
smearing consists of a blocking of hnk variables using e.g. an APE type blocking 

t/^ (n) ^ PoUf, («) + pi £ [Uyin)U^ (n + v)Ul{n + /I) + [/t(„ _ v)[/^ {n - v)Uy{n - V + A)] 

and a projection onto the SU(3) group (unitarization) using e.g. a stout procedure. One repeats 
the set of "blocking" and "unitarization" several times. QCDml therefore marks up link smearing 
procedures as 
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<linkSmearing> 

<apeLinkBlocking> <rhoO/> <rhol/> </apeLinkBlocking> 

<stoutLinkUnitarization/> 

<numSmear /> 
</ linkSmearing> 

In addition to the above example, we currently support <anisotropicApeLinkBlocking> and <in- 
vSqrtLinkUnitarization>. The strategy of inserting an optional <linkSmearing> block to all actions 
makes it easy to markup various fat Unk actions. 



4. Algorithm Part 

Marking up algorithms is realized with a strategy different from that for actions. Due to 
the variety and complexity of algorithms, a generic hierarchical markup is difficult. Moreover, it 
is unlikely that the algorithm would form the primary search criteria. Therefore, algorithms are 
marked up in a rather unconstrained way. 

The algorithm part in the ensemble XML looks like <algorithm> <name/> <glossary/> <refer- 
ence/> <exact/> <parameters/> </algorithm>. The name of the algorithm is given by contributors as a 
value of the <name> element. <glossary> and <reference> elements, also unconstrained, refer to 
the URL of a document and an article reference, respectively. The only constrained element <ex- 
act> provides information of whether the algorithm is exact (true) or not (false). The <parameters> 
block contains a list of <name> and <value> pairs like 

<parameters> 

<name>PHMC_Polynomial_Order</name> <value>2 5 0</value> 
<name>PHMC_Polynomial_Type</name> <value>Chebyshev</ value> 
<name>HMC_MD_dt</name> <value>0 . 400000000E-02</value> 

<name>HMC_MD_steps</name> <value>2 5 0</value> 

</parameters> 

Algorithm parameters might be changed when generating an ensemble. For example, the 
molecular dynamics step size of HMC is often tuned in a run. Contributors can mark up such 
configuration dependent parameters in the <algorithm> part of the configuration XML. 

In addition to the <parameters> list, contributors can import a collaboration specific namespace 
and mark up algorithm parameters in a hierarchical way. Information given in this way is utilized 
only within the collaboration. 



5. Management Part 

The <management> part of the ensemble XML describes information for the XML document 
itself. This part includes <collaboration>, <projectName>, optional <ensembleLabel> and <refer- 
ence>. These elements provide users with a starting point to search useful ensembles. The <man- 
agement> part of the configuration XML includes <crcCheckSum> which is a crc check sum of 
the binary data part of the configuration file Checking this value ensures that the configuration 
is successfully transfered from the ILDG. 

In addition, we can record operations (add, replace, remove) affecting an ensemble XML doc- 
ument in the MDC together with the time stamp and the participant responsible for the operation. 
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Similarly, operations (generate, add, replace, remove) affecting a configuration (or configuration 
XML metadata) are recorded in the <management> part of the configuration XML. Marking up 
these operations is optional, except for the information when a configuration has been generated. 



6. Summary and Future Work 

At present, interoperability of the regional grids has been achieved [ pl| ] for download opera- 
tions and valuable configurations have already been archived [Q] in the grid. Because the ILDG is 
becoming a new research infrastructure for the lattice QCD community, the MDWG encourages 
our colleagues to mark up their ensembles and configurations using QCDml. 

The description of QCDml given in this report is not complete. To study more about QCDml, 



please visit the ILDG MDWG web site [ |10| ] where you can find sample XML documents together 
with human readable documents generated from annotations embedded in the QCDml schema. 

The lattice actions used in simulations are becoming more and more complicated. We plan to 
prepare human readable documents including mathematical expressions and reference articles in 
the near future. We are going to update QCDml continuously to meet community requirements. 

We are grateful to all members of the ILDG Metadata Working Group, in particular to C. DeTar for 
helpful suggestions on the manuscript. T.Y. is partly supported by the Grant-in-Aid of the Ministry 
of Education (No. 18104005 ) of the Japanese Government. 



References 

[1] C. T. H. Davies, A. C. Irving, R. D. Kenway and C. M. Maynard [UKQCD collaboration]. 
International Lattice Data Grid, Nucl. Phys. (Proc. Suppl.) 119 (2003) 225 [hep-lat/0209121]. 

[2] A. C. Irving, R .D. Kenway, C. M. Maynard and T. Yoshie, Progress in building an International 
Lattice Data Grid, Nucl. Phys. (Proc.Suppl.) 129 (2004) 159 [hep-lat/0309029]. 

[3] A. Ukawa, Status of International Lattice Data Grid- An Overview -, Nucl. Phys. (Proc. Suppl.) 140 
(2005) 207 [hep-lat/0409084]; 

K. Jansen, Status Report on ILDG activities, PoS(LAT2006)013 [hep-lat/0609012]. 

[4] C. DeTar, Sharing Lattices Throughout the World: An ILDG Status Report, these proceedings. 

[5] Working group members: G. Andronico (INFN), P. Coddington (Adelaide), C. DeTar (Utah), 

R. Edwards (JLAB), B. Joo (JLAB), C. M. Maynard (Edinburgh), D. Pleiter (NIC/DESY), J. Simone 
(FNAL), T. Yoshie (Tsukuba) 

[6] C. M. Maynard and D. Pleiter, QCDml: First milestone for building an International Lattice Data 
Grid, Nucl. Phys. (Proc. Suppl.) 140 (2005) 213 [hep-lat/0409055]. 

[7] B. Joo and C .M. Maynard, Progress in building the International Lattice Data Grid, 
PoS(LAT2006)028. 

[8] http://www.lqcd.org/ildg 

[9] http://www-zeuthen.desy.der pleiter/ildg/#filefmt 
[10] http://www.ccs.tsukuba.ac.jp/ILDG/ 

[11] D. Pleiter et al. [ILDG Middleware Working Group], Towards an interoperable International Lattice 
Datagrid, these proceedings. 



7 



